home *** CD-ROM | disk | FTP | other *** search
/ SuperHack / SuperHack CD.bin / Hack / INTERNET / TCPIP__1.ZIP / TCPIP_~1.TXT
Encoding:
Text File  |  1996-04-27  |  63.0 KB  |  1,275 lines

  1.  
  2.  
  3. Security Problems in the  TCP/IP Protocol Suite
  4.  
  5. S.M. Bellovin* smb@ulysses.att.com
  6.  
  7. AT&T Bell Laboratories Murray Hill, New Jersey 07974
  8.  
  9. ABSTRACT
  10.  
  11. The  TCP/IP  protocol  suite,  which  is  very  widely  used  today,  was
  12. developed under the sponsorship of the Department of Defense.  Despite that,
  13. there are a number of serious security flaws inherent in the protocols,
  14. regardless of the correctness of any implementations.  We describe a variety
  15. of attacks based on these flaws, including sequence number spoofing, routing
  16. attacks, source address spoofing, and authentication attacks.  We also
  17. present defenses against these attacks, and conclude with a discussion of
  18. broad-spectrum defenses such as encryption.
  19.  
  20. 1.  INTRODUCTION
  21.  
  22. The  TCP/IP  protocol  suite [1][2] ,  which  is  very  widely  used  today,
  23. was developed under the sponsorship of the Department of Defense.  Despite
  24. that, there are a number of serious security flaws inherent in the
  25. protocols.  Some of these flaws exist because hosts rely on IP source
  26. address for authentication; the Berkeley ``r-utilities'' [3] are a notable
  27. example.  Others exist because network control mechanisms, and in particular
  28. routing protocols, have minimal or non-existent authentication.
  29.  
  30. When  describing  such  attacks,  our  basic  assumption  is  that  the
  31. attacker has more or less complete control over some machine connected to
  32. the Internet.  This may be due to flaws in that machine's own protection
  33. mechanisms, or it may be because that machine is a microcomputer, and
  34. inherently unprotected.  Indeed, the attacker may even be a rogue system
  35. administrator.
  36.  
  37. 1.1  Exclusions
  38.  
  39. We  are  not  concerned  with  flaws  in  particular  implementations  of
  40. the protocols, such as those used by the Internet ``worm'' [4][5][6] . 
  41. Rather, we discuss generic problems with the protocols themselves.  As will
  42. be seen, careful implementation techniques can alleviate or prevent some of
  43. these problems.  Some of the protocols we discuss are derived from
  44. Berkeley's version of the UNIX (R) system; others are generic Internet
  45. protocols.
  46.  
  47. We  are  also  not  concerned  with  classic  network  attacks,  such  as
  48. physical eavesdropping, or altered or injected messages.  We discuss such
  49. problems only in so far as they are facilitated or possible because of
  50. protocol problems.
  51.  
  52. For  the  most  part,  there  is  no  discussion  here  of  vendor-specific
  53. protocols.  We do discuss some problems with Berkeley's protocols, since
  54. these have become de facto standards for many vendors, and not just for UNIX
  55. systems.
  56.  
  57. 2.  TCP SEQUENCE NUMBER PREDICTION
  58.  
  59. One  of  the  more  fascinating  security  holes  was  first  described  by
  60. Morris [7] .  Briefly, he used TCP sequence number prediction to construct a
  61. TCP packet sequence without ever receiving any responses from the server. 
  62. This allowed him to spoof a trusted host on a local network.
  63.  
  64. __________________
  65.  
  66. *  Author's address: Room 3C-536B AT&T Bell Laboratories, 600 Mountain
  67. Avenue, Murray Hill, New Jersey 07974.
  68.  
  69. Reprinted from Computer Communication Review, Vol. 19, No. 2, pp. 32-48,
  70. April 1989.
  71.  
  72. - 2 -
  73.  
  74. The normal TCP connection establishment sequence involves a 3-way handshake. 
  75. The client selects and transmits an initial sequence number ISN C , the
  76. server acknowledges it and sends its own sequence number ISN S , and the
  77. client acknowledges that.  Following those three messages, data transmission
  78. may take place.  The exchange may be shown schematically as follows:
  79.  
  80. C*S:SYN(ISN C ) S*C:SYN(ISN S ) ,ACK(ISN C ) C*S:ACK(ISN S ) C*S:data and /
  81. or S*C:data
  82.  
  83. That is, for a conversation to take place, C must first hear ISN S , a more
  84. or less random number.
  85.  
  86. Suppose, though, that there was a way for  an intruder X to predict  ISN S . 
  87. In that case, it could send the following sequence to impersonate trusted
  88. host T:
  89.  
  90. X*S:SYN(ISN X ) ,SRC = T S*T:SYN(ISN S ) ,ACK(ISN X ) X*S:ACK(ISN S ) ,SRC =
  91. T X*S:ACK(ISN S ) ,SRC = T,nasty - data
  92.  
  93. Even though the message S*T does not go to X, X was able to know its
  94. contents, and hence could send data.  If X were to perform this attack on a
  95. connection that allows command execution (i.e., the Berkeley rsh server),
  96. malicious commands could be executed.
  97.  
  98. How,  then,  to  predict  the  random ISN?  In  Berkeley  systems,  the
  99. initial sequence number variable is incremented by a constant amount once
  100. per second, and by half that amount each time a connection is initiated. 
  101. Thus, if one initiates a legitimate connection and observes the ISN S used,
  102. one can calculate, with a high degree of confidence, ISN S * used on the
  103. next connection attempt.
  104.  
  105. Morris points out that the reply message
  106.  
  107. S*T:SYN(ISN S ) ,ACK(ISN X )
  108.  
  109. does  not in  fact vanish down  a  black hole;  rather,  the  real host T
  110. will receive it and attempt to reset the connection.  This is not a serious
  111. obstacle.  Morris found that by impersonating a server port on T, and by
  112. flooding that port with apparent connection requests, he could generate
  113. queue overflows that would make it likely that the S*T message would be
  114. lost.  Alternatively, one could wait until T was down for routine
  115. maintenance or a reboot.
  116.  
  117. A  variant  on  this  TCP  sequence  number  attack,  not  described  by
  118. Morris, exploits the netstat [8] service. In this attack, the intruder
  119. impersonates a host that is down.  If netstat is available on the target
  120. host, it may supply the necessary sequence number information on another
  121. port; this eliminates all need to guess 1 .
  122.  
  123. Defenses Obviously,  the  key  to  this  attack  is  the  relatively  coarse
  124. rate of change of the initial sequence number variable on Berkeley systems. 
  125. The TCP specification requires that this variable be incremented
  126. approximately 250,000 times per second; Berkeley is using a much slower
  127. rate.  However, the critical factor is the granularity, not the average
  128. rate.  The change from an increment of 128 per second in 4.2BSD to 125,000
  129. per second in 4.3BSD is meaningless, even though the latter is within a
  130. factor of two of the specified rate.
  131.  
  132. __________________
  133.  
  134. 1.  The netstat protocol is obsolete, but is still present on some Internet
  135. hosts.  Security concerns were not behind its elimination.
  136.  
  137. - 3 -
  138.  
  139. Let  us  consider  whether  a  counter  that  operated  at  a  true  250,000
  140. hz rate would help.  For simplicity's sake, we will ignore the problem of
  141. other connections occurring, and only consider the fixed rate of change of
  142. this counter.
  143.  
  144. To learn a current sequence number, one must send a SYN packet, and receive
  145. a response, as follows:
  146.  
  147. X*S: SYN(ISN X ) S*X: SYN(ISN S ) ,ACK(ISN X )  (1)
  148.  
  149. The  first  spoof  packet,  which  triggers  generation  of  the  next
  150. sequence number, can immediately follow the server's response to the probe
  151. packet:
  152.  
  153. X*S: SYN(ISN X ) ,SRC = T (2)
  154.  
  155. The sequence number ISN S used in the response
  156.  
  157. S*T: SYN(ISN S ) ,ACK(ISN X )
  158.  
  159. is  uniquely  determined  by  the  time  between  the  origination  of
  160. message (1) and the receipt at the server of message (1).  But this number
  161. is precisely the round-trip time between X and S.  Thus, if the spoofer can
  162. accurately measure (and predict) that time, even a 4 u-second clock will not
  163. defeat this attack.
  164.  
  165. How  accurately  can  the  trip  time  be  measured?  If  we  assume  that
  166. stability is good, we can probably bound it within 10 milliseconds or so. 
  167. Clearly, the Internet does not exhibit such stability over the long-term [9]
  168. , but it is often good enough over the short term. 2 There is thus an
  169. uncertainty of 2500 in the possible value for ISN S .  If each trial takes 5
  170. seconds, to allow time to re-measure the round-trip time, an intruder would
  171. have a reasonable likelihood of succeeding in 7500 seconds, and a
  172. near-certainty within a day.  More predictable (i.e., higher quality)
  173. networks, or more accurate measurements, would improve the odds even further
  174. in the intruder's favor.  Clearly, simply following the letter of the TCP
  175. specification is not good enough.
  176.  
  177. We  have  thus  far  tacitly  assumed  that  no  processing  takes  places
  178. on the target host.  In fact, some processing does take place when a new
  179. request comes in; the amount of variability in this processing is critical. 
  180. On a 6 MIPS machine, one tick -- 4 u-seconds -- is about 25 instructions. 
  181. There is thus considerable sensitivity to the exact instruction path
  182. followed.  High-priority interrupts, or a slightly different TCB allocation
  183. sequence, will have a comparatively large effect on the actual value of the
  184. next sequence number.  This randomizing effect is of considerable advantage
  185. to the target.  It should be noted, though, that faster machines are more
  186. vulnerable to this attack, since the variability of the instruction path
  187. will take less real time, and hence affect the increment less.  And of
  188. course, CPU speeds are increasing rapidly.
  189.  
  190. This  suggests  another  solution  to  sequence  number  attacks:
  191. randomizing the increment.  Care must be taken to use sufficient bits; if,
  192. say, only the low-order 8 bits were picked randomly, and the granularity of
  193. the increment was coarse, the intruder's work factor is only multiplied by
  194. 256.  A combination of a fine-granularity increment and a small random
  195. number generator, or just a 32-bit generator, is better. Note, though, that
  196. many pseudo-random number generators are easily invertible [10] .  In fact,
  197. given that most such generators work via feedback of their output, the enemy
  198. could simply compute the next ``random'' number to be picked.  Some hybrid
  199. techniques have promise -- using a 32-bit generator, for example, but only
  200. emitting 16 bits of it -- but brute-force attacks could succeed at
  201. determining the seed. One would need at least 16 bits of random data in each
  202. increment, and perhaps more, to defeat probes from the network, but that
  203. might leave too few bits to guard against a search for the seed.  More
  204. research or simulations are needed to determine the proper parameters.
  205.  
  206. __________________
  207.  
  208. 2.  At the moment, the Internet may not have such stability even over the
  209. short-term, especially on long-haul connections.  It is not comforting to
  210. know that the security of a network relies on its low quality of service.
  211.  
  212. - 4 -
  213.  
  214. Rather  than  go  to  such  lengths,  it  is  simpler  to  use  a
  215. cryptographic algorithm (or device) for ISN S generation.  The Data
  216. Encryption Standard [11] (DES) in electronic codebook mode [12] is an
  217. attractive choice as the ISN S source, with a simple counter as input. 
  218. Alternatively, DES could be used in output feedback mode without an
  219. additional counter.  Either way, great care must be taken to select the key
  220. used.  The time-of-day at boot time is not adequate; sufficiently good
  221. information about reboot times is often available to an intruder, thereby
  222. permitting a brute-force attack.  If, however, the reboot time is encrypted
  223. with a per-host secret key, the generator cannot be cracked with any
  224. reasonable effort.
  225.  
  226. Performance  of  the  initial  sequence  number  generator  is  not  a
  227. problem.  New sequence numbers are needed only once per connection, and even
  228. a software implementation of DES will suffice.  Encryption times of 2.3
  229. milliseconds on a 1 MIPS processor have been reported [13] .
  230.  
  231. An  additional  defense  involves  good  logging  and  alerting  mechanisms. 
  232. Measurements of the round-trip time -- essential for attacking RFC-compliant
  233. hosts -- would most likely be carried out using ICMP Ping messages; a
  234. ``transponder'' function could log excessive ping requests.  Other, perhaps
  235. more applicable, timing measurement techniques would involve attempted TCP
  236. connections; these connections are conspicuously short-lived, and may not
  237. even complete SYN processing.  Similarly, spoofing an active host will
  238. eventually generate unusual types of RST packets; these should not occur
  239. often, and should be logged.
  240.  
  241. 3.  THE JOY OF ROUTING
  242.  
  243. Abuse of  the  routing  mechanisms  and protocols  is probably  the
  244. simplest protocol-based attack available. There are a variety of ways to do
  245. this, depending on the exact routing protocols used.  Some of these attacks
  246. succeed only if the remote host does source address-based authentication;
  247. others can be used for more powerful attacks.
  248.  
  249. A  number  of the  attacks described  below  can  also  be  used  to
  250. accomplish denial of service by confusing the routing tables on a host or
  251. gateway.  The details are straight-forward corollaries of the penetration
  252. mechanisms, and will not be described further.
  253.  
  254. 3.1  Source Routing
  255.  
  256. If  available,  the  easiest  mechanism  to  abuse  is  IP  source  routing. 
  257. Assume that the target host uses the reverse of the source route provided in
  258. a TCP open request for return traffic.  Such behavior is utterly reasonable;
  259. if the originator of the connection wishes to specify a particular path for
  260. some reason -- say, because the automatic route is dead -- replies may not
  261. reach the originator if a different path is followed.
  262.  
  263. The  attacker  can  then  pick  any  IP  source  address  desired,
  264. including that of a trusted machine on the target's local network.  Any
  265. facilities available to such machines become available to the attacker.
  266.  
  267. Defenses It  is  rather  hard  to  defend  against  this  sort  of  attack. 
  268. The best idea would be for the gateways into the local net to reject
  269. external packets that claim to be from the local net.  This is less
  270. practical than it might seem since some Ethernet 3 network adapters receive
  271. their own transmissions, and this feature is relied upon by some
  272. higher-level protocols.  Furthermore, this solution fails completely if an
  273. organization has two trusted networks connected via a multi-organization
  274. backbone.  Other users on the backbone may not be trustable to the same
  275. extent that local users are presumed to be, or perhaps their vulnerability
  276. to outside attack is higher.  Arguably, such topologies should be avoided in
  277. any event.
  278.  
  279. A  simpler  method  might  be  to  reject  pre-authorized  connections  if
  280. source routing information was present.  This presumes that there are few
  281. legitimate reasons for using this IP option, especially for
  282.  
  283. __________________
  284.  
  285. 3.  Ethernet is a registered trademark of Xerox Corporation.
  286.  
  287. - 5 -
  288.  
  289. relatively  normal  operations.  A  variation  on  this  defense  would  be
  290. to analyze the source route and accept it if only trusted gateways were
  291. listed; that way, the final gateway could be counted on to deliver the
  292. packet only to the true destination host.  The complexity of this idea is
  293. probably not worthwhile.
  294.  
  295. Some protocols (i.e., Berkeley's rlogin and rsh) permit ordinary users to
  296. extend trust to remote host/user combinations.  In that case, individual
  297. users, rather than an entire system, may be targeted by source routing
  298. attacks. 4 Suspicious gateways [14] will not help here, as the host being
  299. spoofed may not be within the security domain protected by the gateways.
  300.  
  301. 3.2  Routing Information Protocol Attacks
  302.  
  303. The Routing  Information  Protocol [15] (RIP)  is  used  to  propagate
  304. routing information on local networks, especially broadcast media. 
  305. Typically, the information received is unchecked.  This allows an intruder
  306. to send bogus routing information to a target host, and to each of the
  307. gateways along the way, to impersonate a particular host.  The most likely
  308. attack of this sort would be to claim a route to a particular unused host,
  309. rather than to a network; this would cause all packets destined for that
  310. host to be sent to the intruder's machine.  (Diverting packets for an entire
  311. network might be too noticeable; impersonating an idle work-station is
  312. comparatively risk-free.) Once this is done, protocols that rely on
  313. address-based authentication are effectively compromised.
  314.  
  315. This  attack  can  yield  more  subtle,  and  more  serious,  benefits  to
  316. the attacker as well.  Assume that the attacker claims a route to an active
  317. host or workstation instead.  All packets for that host will be routed to
  318. the intruder's machine for inspection and possible alteration.  They are
  319. then resent, using IP source address routing, to the intended destination. 
  320. An outsider may thus capture passwords and other sensitive data.  This mode
  321. of attack is unique in that it affects outbound calls as well; thus, a user
  322. calling out from the targeted host can be tricked into divulging a password. 
  323. Most of the earlier attacks discussed are used to forge a source address;
  324. this one is focused on the destination address.
  325.  
  326. Defenses A RIP attack is somewhat easier to defend against than the
  327. source-routing attacks, though some defenses are similar.  A paranoid
  328. gateway -- one that filters packets based on source or destination address
  329. -- will block any form of host-spoofing (including TCP sequence number
  330. attacks), since the offending packets can never make it through.  But there
  331. are other ways to deal with RIP problems.
  332.  
  333. One  defense  is  for  RIP  to  be  more  skeptical  about  the  routes  it
  334. accepts.  In most environments, there is no good reason to accept new routes
  335. to your own local networks.  A router that makes this check can easily
  336. detect intrusion attempts.  Unfortunately, some implementations rely on
  337. hearing their own broadcasts to retain their knowledge of directly-attached
  338. networks.  The idea, presumably, is that they can use other networks to
  339. route around local outages.  While fault-tolerance is in general a good
  340. idea, the actual utility of this technique is low in many environments
  341. compared with the risks.
  342.  
  343. It  would  be  useful  to  be  able  to  authenticate  RIP  packets;  in
  344. the absence of inexpensive public-key signature schemes, this is difficult
  345. for a broadcast protocol.  Even if it were done, its utility is limited; a
  346. receiver can only authenticate the immediate sender, which in turn may have
  347. been deceived by gateways further upstream.
  348.  
  349. Even  if  the  local  routers  don't  implement  defense  mechanisms,  RIP
  350. attacks carry another risk: the bogus routing entries are visible over a
  351. wide area.  Any router (as opposed to host) that receives such data will
  352. rebroadcast it; a suspicious administrator almost anywhere on the local
  353. collection of networks could notice the anomaly.  Good log generation would
  354. help, but it is hard to distinguish a genuine intrusion from the routing
  355. instability that can accompany a gateway crash.
  356.  
  357. __________________
  358.  
  359. 4.  Permitting  ordinary  users  to  extend  trust  is  probably  wrong  in
  360. any event, regardless of abuse of the protocols.  But such concerns are
  361. beyond the scope of this paper.
  362.  
  363. - 6 -
  364.  
  365. 3.3  Exterior Gateway Protocol
  366.  
  367. The Exterior  Gateway  Protocol (EGP) [16] is  intended  for  communications
  368. between the core gateways and so-called exterior gateways.  An exterior
  369. gateway, after going through a neighbor acquisition protocol, is
  370. periodically polled by the core; it responds with information about the
  371. networks it serves. These networks must all be part of its autonomous
  372. system.  Similarly, the gateway periodically requests routing information
  373. from the core gateway.  Data is not normally sent except in response to a
  374. poll; furthermore, since each poll carries a sequence number that must be
  375. echoed by the response, it is rather difficult for an intruder to inject a
  376. false route update.  Exterior gateways are allowed to send exactly one
  377. spontaneous update between any two polls; this, too, must carry the sequence
  378. number of the last poll received.  It is thus comparatively difficult to
  379. interfere in an on-going EGP conversation.
  380.  
  381. One  possible  attack  would  be  to  impersonate  a  second  exterior
  382. gateway for the same autonomous system.  This may not succeed, as the core
  383. gateways could be equipped with a list of legitimate gateways to each
  384. autonomous system.  Such checks are not currently done, however.  Even if
  385. they were, they could be authenticated only by source IP address.
  386.  
  387. A  more  powerful  attack  would  be  to  claim  reachability  for  some
  388. network where the real gateway is down.  That is, if gateway G normally
  389. handles traffic for network N, and G is down, gateway G*could advertise a
  390. route to that network.  This would allow password capture by assorted
  391. mechanisms.  The main defense against this attack is topological (and quite
  392. restrictive): exterior gateways must be on the same network as the core;
  393. thus, the intruder would need to subvert not just any host, but an existing
  394. gateway or host that is directly on the main net.
  395.  
  396. A  sequence  number  attack,  similar  to  those  used  against  TCP,  might
  397. be attempted; the difficulty here is in predicting what numbers the core
  398. gateway is using.  In TCP, one can establish arbitrary connections to probe
  399. for information; in EGP, only a few hosts may speak to the core.  (More
  400. accurately, the core could only speak to a few particular hosts, though as
  401. noted such checks are not currently implemented.) It may thus be hard to get
  402. the raw data needed for such an attack.
  403.  
  404. 3.4  The Internet Control Message Protocol
  405.  
  406. The Internet  Control  Message  Protocol (ICMP) [17] is  the  basic  network
  407. management tool of the TCP/IP protocol suite.  It would seem to carry a rich
  408. potential for abuse.  Surprisingly, ICMP attacks are rather difficult;
  409. still, there are often holes that may be exploited.
  410.  
  411. The first, and most obvious target, is the ICMP Redirect message; it is used
  412. by gateways to advise hosts of better routes.  As such it can often be
  413. abused in the same way that RIP can be.  The complication is that a Redirect
  414. message must be tied to a particular, existing connection; it cannot be used
  415. to make an unsolicited change to the host's routing tables.  Furthermore,
  416. Redirects are only applicable within a limited topology; they may be sent
  417. only from the first gateway along the path to the originating host.  A later
  418. gateway may not advise that host, nor may it use ICMP Redirect to control
  419. other gateways.
  420.  
  421. Suppose,  though,  that  an  intruder  has  penetrated  a  secondary
  422. gateway available to a target host, but not the primary one.  (It may
  423. suffice to penetrate an ordinary host on the target's local network, and
  424. have it claim to be a gateway.) Assume further that the intruder wishes to
  425. set up a false route to trusted host T through that compromised secondary
  426. gateway.  The following sequence may then be followed.  Send a false TCP
  427. open packet to the target host, claiming to be from T.  The target will
  428. respond with its own open packet, routing it through the secure primary
  429. gateway.  While this is in transit, a false Redirect may be sent, claiming
  430. to be from the primary gateway, and referring to the bogus connection.  This
  431. packet will appear to be a legitimate control message; hence the routing
  432. change it contains will be accepted.  If the target host makes this change
  433. to its global routing tables, rather than just to the per connection cached
  434. route, the intruder may proceed with spoofing host T.
  435.  
  436. Some  hosts  do  not  perform  enough  validity  checks  on  ICMP  Redirect
  437. messages; in such cases, the impact of this attack becomes similar to
  438. RIP-based attacks.
  439.  
  440. ICMP  may  also  be  used  for  targeted  denial  of  service  attacks. 
  441. Several of its messages, such as Destination Unreachable and Time to Live
  442. Exceeded, may be used to reset existing connections.  If the
  443.  
  444. - 7 -
  445.  
  446. intruder  knows  the  local  and  remote  port  numbers  of  a  TCP
  447. connection, an ICMP packet aimed at that connection may be forged 5 .  Such
  448. information is sometimes available through the netstat service.
  449.  
  450. A  more  global  denial  of  service  attack  can  be  launched  by  sending
  451. a fraudulent Subnet Mask Reply message.  Some hosts will accept any such
  452. message, whether they have sent a query or not; a false one could
  453. effectively block all communications with the target host.
  454.  
  455. Defenses Most  ICMP  attacks  are  easy  to  defend  against  with  just  a
  456. modicum of paranoia.  If a host is careful about checking that a message
  457. really does refer to a particular connection, most such attacks will not
  458. succeed.  In the case of TCP, this includes verifying that the ICMP packet
  459. contains a plausible sequence number in the returned-packet portion.  These
  460. checks are less applicable to UDP, though.
  461.  
  462. A  defense  against  Redirect  attacks  merits  additional  attention,
  463. since such attacks can be more serious. Probably, the best option is to
  464. restrict route changes to the specified connection; the global routing table
  465. should not be modified in response to ICMP Redirect messages 6 .
  466.  
  467. Finally,  it  is  worth  considering  whether  ICMP  Redirects  are  even
  468. useful in today's environment.  They are only usable on local networks with
  469. more than one gateway to the outside world.  But it is comparatively easy to
  470. maintain complete and correct local routing information.  Redirect messages
  471. would be most useful from the core gateways to local exterior gateways, as
  472. that would allow such local gateways to have less than complete knowledge of
  473. the Internet; this use is disallowed, however.
  474.  
  475. Subnet  Mask  attacks  can  be  blocked  if  the  Reply  packet  is  honored
  476. only at the appropriate time.  In general, a host wants to see such a
  477. message only at boot time, and only if it had issued a query; a stale reply,
  478. or an unsolicited reply, should be rejected out of hand.  There is little
  479. defense against a forged reply to a genuine Subnet Mask query, as a host
  480. that has sent such a query typically has few resources with which to
  481. validate the response.  If the genuine response is not blocked by the
  482. intruder, though, the target will receive multiple replies; a check to
  483. ensure that all replies agree would guard against administrative errors as
  484. well.
  485.  
  486. 4.  THE ``AUTHENTICATION'' SERVER
  487.  
  488. As  an  alternative  to  address-based  authentication,  some
  489. implementations use the Authentication Server [18] .  A server that wishes
  490. to know the identity of its client may contact the client host's
  491. Authentication Server 7 , and ask it for information about the user owning a
  492. particular connection.  This method is inherently more secure than simple
  493. address-based authentication, as it uses a second TCP connection not under
  494. control of the attacker.  It thus can defeat sequence number attacks and
  495. source routing attacks.  There are certain risks, however.
  496.  
  497. The  first,  and  most  obvious,  is  that  not  all  hosts  are  competent
  498. to run authentication servers.  If the client host is not secure, it does
  499. not matter who the user is claimed to be; the answer cannot be trusted.
  500. Second, the authentication message itself can be compromised by routing
  501. table attacks.  If RIP has been used to alter the target's idea of how to
  502. reach some host, the authentication query will rely on the same altered
  503. routing data.  Finally, if the target host is down, a variant on the TCP
  504. sequence number attack may be used; after the server sends out a TCP open
  505. request to the presumed authentication server, the attacker can complete the
  506. open sequence and send a false reply.  If the target runs a netstat server,
  507. this is even easier; as noted, netstat will often supply the necessary
  508. sequence numbers with no need to guess.
  509.  
  510. __________________
  511.  
  512. 5.  In fact, such programs are available today; they are used as
  513. administrative tools to reset hung TCP connections.
  514.  
  515. 6.  This has other benefits as well, especially in environments where
  516. ICMP-initiated route changes are not timed out.  The author has seen
  517. situations where RIP instability following a gateway crash has led to
  518. erroneous ICMP Redirect messages.  These had the effect of permanently
  519. corrupting the routing tables on other hosts.
  520.  
  521. 7.  The  Internet  Activities  Board  does  not  currently  recommend  the
  522. Authentication Server for implementation [19] .  However, the decision was
  523. not made because of security problems [5] .
  524.  
  525. - 8 -
  526.  
  527. A less-obvious risk is that a fake authentication server can always reply
  528. ``no''.  This constitutes a denial of service attack.
  529.  
  530. Defenses A  server  that  wishes  to  rely  on  another  host's  idea  of  a
  531. user should use a more secure means of validation, such as the
  532. Needham-Schroeder algorithm [20][21][22] .  TCP by itself is inadequate.
  533.  
  534. 5.  HERE BE DRAGONS
  535.  
  536. Some protocols, while not inherently flawed, are nevertheless susceptible to
  537. abuse.  A wise implementor would do well to take these problems into account
  538. when providing the service.
  539.  
  540. 5.1  The ``Finger'' Service
  541.  
  542. Many  systems  implement  a finger service [23] .  This  server  will
  543. display useful information about users, such as their full names, phone
  544. numbers, office numbers, etc.  Unfortunately, such data provides useful
  545. grist for the mill of a password cracker. [24] By running such a service, a
  546. system administrator is giving away this data.
  547.  
  548. 5.2  Electronic Mail
  549.  
  550. Electronic mail is probably the most valuable service on the Internet. 
  551. Nevertheless, it is quite vulnerable to misuse.  As normally implemented
  552. [25][26] , the mail server provides no authentication mechanisms. This
  553. leaves the door wide open to faked messages.  RFC 822 does support an
  554. Encrypted header line, but this is not widely used.  (However, see RFC 1040
  555. [27] for a discussion of a proposed new encryption standard for electronic
  556. mail.)
  557.  
  558. 5.2.1  The Post Office Protocol
  559.  
  560. The The  Post  Office  Protocol (POP) [28] allows  a  remote  user  to
  561. retrieve mail stored on a central server machine.  Authentication is by
  562. means of a single command containing both the user name and the password. 
  563. However, combining the two on a single command mandates the use of
  564. conventional passwords.  And such passwords are becoming less popular; they
  565. are too vulnerable to wire-tappers, intentional or accidental disclosure,
  566. etc.
  567.  
  568. As  an  alternative,  many  sites  are  adopting  ``one-time  passwords'' 8
  569. .  With one-time passwords, the host and some device available to the user
  570. share a cryptographic key.  The host issues a random challenge; both sides
  571. encrypt this number, and the user transmits it back to the host.  Since the
  572. challenge is random, the reply is unique to that session, thereby defeating
  573. eavesdroppers.  And since the user does not know the key -- it is
  574. irretrievably stored in the device -- the password cannot be given away
  575. without depriving the user of the ability to log in.
  576.  
  577. The  newest  version  of  POP [30] has  split  the  user  name  and
  578. password into two commands, which is useful.  However, it also defines an
  579. optional mechanism for preauthenticated connections, typically using
  580. Berkeley's mechanisms.  Commendably, the security risks of this variant are
  581. mentioned explicitly in the document.
  582.  
  583. 5.2.2  PCMAIL
  584.  
  585. The PCMAIL protocol [31] uses  authentication  mechanisms  similar  to
  586. those in POP2.  In one major respect, PCMAIL is more dangerous: it supports
  587. a password-change command.  This request requires that both the old and new
  588. passwords be transmitted unencrypted.
  589.  
  590. __________________
  591.  
  592. 8.  One-time passwords were apparently first used for military IFF
  593. (Identification Friend or Foe) systems [29] .
  594.  
  595. - 9 -
  596.  
  597. 5.3  The Domain Name System
  598.  
  599. The Domain  Name  System (DNS) [32][33] provides  for  a  distributed
  600. database mapping host names to IP addresses.  An intruder who interferes
  601. with the proper operation of the DNS can mount a variety of attacks,
  602. including denial of service and password collection.  There are a number of
  603. vulnerabilities.
  604.  
  605. In  some  resolver  implementations,  it  is  possible  to  mount  a
  606. sequence number attack against a particular user.  When the target user
  607. attempts to connect to a remote machine, an attacker can generate a domain
  608. server response to the target's query.  This requires knowing both the UDP
  609. port used by the client's resolver and the DNS sequence number used for the
  610. query.  The latter is often quite easy to obtain, though, since some
  611. resolvers always start their sequence numbers with 0.  And the former may be
  612. obtainable via netstat or some analogous host command.
  613.  
  614. A combined attack on the domain system and the routing mechanisms can be
  615. catastrophic.  The intruder can intercept virtually all requests to
  616. translate names to IP addresses, and supply the address of a subverted
  617. machine instead; this would allow the intruder to spy on all traffic, and
  618. build a nice collection of passwords if desired.
  619.  
  620. For  this  reason,  domain  servers  are  high-value  targets;  a
  621. sufficiently determined attacker might find it useful to take over a server
  622. by other means, including subverting the machine one is on, or even
  623. physically interfering with its link to the Internet.  There is no network
  624. defense against the former, which suggests that domain servers should only
  625. run on highly secure machines; the latter issue may be addressed by using
  626. authentication techniques on domain server responses.
  627.  
  628. The DNS, even when functioning correctly, can be used for some types of
  629. spying.  The normal mode of operation of the DNS is to make specific
  630. queries, and receive specific responses.  However, a zone transfer (AXFR)
  631. request exists that can be used to download an entire section of the
  632. database; by applying this recursively, a complete map of the name space can
  633. be produced.  Such a database represents a potential security risk; if, for
  634. example, an intruder knows that a particular brand of host or operating
  635. system has a particular vulnerability, that database can be consulted to
  636. find all such targets. Other uses for such a database include espionage; the
  637. number and type of machines in a particular organization, for example, can
  638. give away valuable data about the size of the organization, and hence the
  639. resources committed to a particular project.
  640.  
  641. Fortunately,  the  domain  system  includes  an  error  code  for
  642. ``refused''; an administrative prohibition against such zone transfers is
  643. explicitly recognized as a legitimate reason for refusal.  This code should
  644. be employed for zone transfer requests from any host not known to be a
  645. legitimate secondary server. Unfortunately, there is no authentication
  646. mechanism provided in the AXFR request; source address authentication is the
  647. best that can be done.
  648.  
  649. Recently,  a  compatible  authentication  extension  to  the  DNS  has  been
  650. devised at M.I.T.  The Hesiod name server [34] uses Kerberos [35] tickets to
  651. authenticate queries and responses.  The additional information section of
  652. the query carries an encrypted ticket, which includes a session key; this
  653. key, known only to Hesiod and the client, is used to compute a cryptographic
  654. checksum of the both the query and the response.  These checksums are also
  655. sent in the additional information field.
  656.  
  657. 5.4  The File Transfer Protocol
  658.  
  659. The File Transfer Protocol (FTP) [36] itself is not flawed.  However,  a
  660. few aspects of the implementation merit some care.
  661.  
  662. 5.4.1  FTP Authentication
  663.  
  664. FTP  relies  on  a  login  and  password  combination  for  authentication. 
  665. As noted, simple passwords are increasingly seen as inadequate; more and
  666. more sites are adopting one-time passwords.  Nothing in the FTP
  667. specification precludes such an authentication method.  It is vital,
  668. however, that the ``331'' response to a USER subcommand be displayed to the
  669. user; this message would presumably contain the challenge.  An FTP
  670. implementation that concealed this response could not be used in this mode;
  671. if such implementations are (or become) common, it may be necessary to use a
  672. new reply code to indicate that
  673.  
  674. - 10 -
  675.  
  676. the user must see the content of the challenge.
  677.  
  678. 5.4.2  Anonymous FTP
  679.  
  680. A second problem area is ``anonymous FTP''.  While not required by the FTP
  681. specification, anonymous FTP is a treasured part of the oral tradition of
  682. the Internet.  Nevertheless, it should be implemented with care.
  683.  
  684. One part of the problem is the implementation technique chosen.  Some
  685. implementations of FTP require creation of a partial replica of the
  686. directory tree; care must be taken to ensure that these files are not
  687. subject to compromise.  Nor should they contain any sensitive information,
  688. such as encrypted passwords.
  689.  
  690. The second problem is that anonymous FTP is truly anonymous; there is no
  691. record of who has requested what information.  Mail-based servers will
  692. provide that data; they also provide useful techniques for load-limiting 9 ,
  693. background transfers, etc.
  694.  
  695. 5.5  Simple Network Management Protocol
  696.  
  697. The Simple  Network  Management  Protocol (SNMP) [37] has  recently  been
  698. defined to aid in network management.  Clearly, access to such a resource
  699. must be heavily protected.  The RFC states this, but also allows for a null
  700. authentication service; this is a bad idea.  Even a ``read-only'' mode is
  701. dangerous; it may expose the target host to netstat-type attacks if the
  702. particular Management Information Base (MIB) [38] used includes sequence
  703. numbers.  (The current standardized version does not; however, the MIB is
  704. explicitly declared to be extensible.)
  705.  
  706. 5.6  Remote Booting
  707.  
  708. Two  sets  of  protocols  are  used  today  to  boot  diskless  workstations
  709. and gateways, Reverse ARP (RARP) [39] with the Trivial File Transfer
  710. Protocol (TFTP) [40] and BOOTP [41] with TFTP.  A system being booted is a
  711. tempting target; if one can subvert the boot process, a new kernel with
  712. altered protection mechanisms can be substituted.  RARP-based booting is
  713. riskier because it relies on Ethernet like networks, with all the
  714. vulnerabilities adhering thereto.  One can achieve a modest improvement in
  715. security by ensuring that the booting machine uses a random number for its
  716. UDP source port; otherwise, an attacker can impersonate the server and send
  717. false DATA packets.
  718.  
  719. BOOTP adds an additional layer of security by including a 4-byte random
  720. transaction id.  This prevents an attacker from generating false replies to
  721. a workstation known to be rebooting.  It is vital that these numbers indeed
  722. be random; this can be difficult in a system that is freshly powered up, and
  723. hence with little or no unpredictable state.  Care should be taken when
  724. booting through gateways; the more networks traversed, the greater the
  725. opportunity for impersonation.
  726.  
  727. The  greatest  measure  of  protection  is  that  normally,  the  attacker
  728. has only a single chance; a system being booted does not stay in that state. 
  729. If, however, communications between the client and the standard server may
  730. be interrupted, larger-scale attacks may be mounted.
  731.  
  732. 6.  TRIVIAL ATTACKS
  733.  
  734. A few attacks are almost too trivial to mention; nevertheless, completeness
  735. demands that they at least be noted.
  736.  
  737. __________________
  738.  
  739. 9.  Recently, a host was temporarily rendered unusable by massive numbers of
  740. FTP requests for a popular technical report.  If this were deliberate, it
  741. would be considered a successful denial of service attack.
  742.  
  743. - 11 -
  744.  
  745. 6.1  Vulnerability of the Local Network
  746.  
  747. Some local-area networks, notably the Ethernet networks, are extremely
  748. vulnerable to eavesdropping and host-spoofing.  If such networks are used,
  749. physical access must be strictly controlled.  It is also unwise to trust any
  750. hosts on such networks if any machine on the network is accessible to
  751. untrusted personnel, unless authentication servers are used.
  752.  
  753. If  the  local  network  uses  the  Address  Resolution  Protocol  (ARP)
  754. [42] more subtle forms of host-spoofing are possible.  In particular, it
  755. becomes trivial to intercept, modify, and forward packets, rather than just
  756. taking over the host's role or simply spying on all traffic.
  757.  
  758. It  is  possible  to  launch  denial  of  service  attacks  by  triggering
  759. broadcast storms.  There are a variety of ways to do this; it is quite easy
  760. if most or all of the hosts on the network are acting as gateways.  The
  761. attacker can broadcast a packet destined for a non-existent IP address. 
  762. Each host, upon receiving it, will attempt to forward it to the proper
  763. destination.  This alone will represent a significant amount of traffic, as
  764. each host will generate a broadcast ARP query for the destination.  The
  765. attacker can follow up by broadcasting an ARP reply claiming that the
  766. broadcast Ethernet address is the proper way to reach that destination. 
  767. Each suspectible host will then not only resend the bogus packet, it will
  768. also receive many more copies of it from the other suspectible hosts on the
  769. network.
  770.  
  771. 6.2  The Trivial File Transfer Protocol
  772.  
  773. TFTP [40] permits  file  transfers  without  any  attempt  at
  774. authentication.  Thus, any publicly-readable file in the entire universe is
  775. accessible.  It is the responsibility of the implementor and/or the system
  776. administrator to make that universe as small as possible.
  777.  
  778. 6.3  Reserved Ports
  779.  
  780. Berkeley-derived  TCPs  and  UDPs  have  the  notion  of  a  ``privileged
  781. port''.  That is, port numbers lower than 1024 may only be allocated to
  782. privileged processes.  This restriction is used as part of the
  783. authentication mechanism.  However, neither the TCP nor the UDP
  784. specifications contain any such concept, nor is such a concept even
  785. meaningful on a single-user computer.  Administrators should never rely on
  786. the Berkeley authentication schemes when talking to such machines.
  787.  
  788. 7.  COMPREHENSIVE DEFENSES
  789.  
  790. Thus  far,  we  have  described  defenses  against  a  variety  of
  791. individual attacks.  Several techniques are broad-spectrum defenses; they
  792. may be employed to guard against not only these attacks, but many others as
  793. well.
  794.  
  795. 7.1  Authentication
  796.  
  797. Many  of  the  intrusions  described  above  succeed  only  because  the
  798. target host uses the IP source address for authentication, and assumes it to
  799. be genuine.  Unfortunately, there are sufficiently many ways to spoof this
  800. address that such techniques are all but worthless.  Put another way, source
  801. address authentication is the equivalent of a file cabinet secured with an
  802. S100 lock; it may reduce the temptation level for more-or-less honest
  803. passers-by, but will do little or nothing to deter anyone even slightly
  804. serious about gaining entry.
  805.  
  806. Some  form  of  cryptographic  authentication  is  needed.  There  are
  807. several possible approaches.  Perhaps the best-known is the
  808. Needham-Schroeder algorithm [20][21][22] .  It relies on each host sharing a
  809. key with an authentication server; a host wishing to establish a connection
  810. obtains a session key from the authentication server and passes a sealed
  811. version along to the destination.  At the conclusion of the dialog, each
  812. side is convinced of the identity of the other.  Versions of the algorithm
  813. exist for both private-key and public-key [43] cryptosystems.
  814.  
  815. How  do  these  schemes  fit  together  with  TCP/IP?  One  answer  is
  816. obvious: with them, preauthenticated connections can be implemented safely;
  817. without them, they are quite risky.  A second answer is that the DNS
  818. provides an ideal base for authentication systems, as it already
  819. incorporates the necessary name structure, redundancy, etc.  To be sure, key
  820. distribution responses must be authenticated and/or
  821.  
  822. - 12 -
  823.  
  824. encrypted; as noted, the former seems to be necessary in any event.
  825.  
  826. In  some  environments,  care  must  be  taken  to  use  the  session  key
  827. to encrypt the entire conversation; if this is not done, an attacker can
  828. take over a connection via the mechanisms described earlier.
  829.  
  830. 7.2  Encryption
  831.  
  832. Suitable  encryption  can  defend  against  most  of  the  attacks  outlined
  833. above.  But encryption devices are expensive, often slow, hard to
  834. administer, and uncommon in the civilian sector.  There are different ways
  835. to apply encryption; each has its strengths and weaknesses.  A comprehensive
  836. treatment of encryption is beyond the scope of this paper; interested
  837. readers should consult Voydock and Kent [44] or Davies and Price [45] .
  838.  
  839. Link-level encryption -- encrypting each packet as it leaves the host
  840. computer -- is an excellent method of guarding against disclosure of
  841. information.  It also works well against physical intrusions; an attacker
  842. who tapped in to an Ethernet cable, for example, would not be able to inject
  843. spurious packets. Similarly, an intruder who cut the line to a name server
  844. would not be able to impersonate it.  The number of entities that share a
  845. given key determines the security of the network; typically, a key
  846. distribution center will allocate keys to each pair of communicating hosts.
  847.  
  848. Link-level  encryption  has  some  weaknesses,  however.  Broadcast  packets
  849. are difficult to secure; in the absence of fast public-key cryptosystems,
  850. the ability to decode an encrypted broadcast implies the ability to send
  851. such a broadcast, impersonating any host on the network.  Furthermore,
  852. link-level encryption, by definition, is not end-to-end; security of a
  853. conversation across gateways implies trust in the gateways and assurance
  854. that the full concatenated internet is similarly protected.  (This latter
  855. constraint may be enforced administratively, as is done in the military
  856. sector.) If such constraints are not met, tactics such as source-routing
  857. attacks or RIP-spoofing may be employed.  Paranoid gateways can be deployed
  858. at the entrance to security domains; these might, for example, block
  859. incoming RIP packets or source-routed packets.
  860.  
  861. Many  portions  of  the  DARPA  Internet  employ  forms  of  link
  862. encryption.  All Defense Data Network (DDN) IMP-to-IMP trunks use DES
  863. encryption, even for non-classified traffic; classified lines use more
  864. secure cryptosystems [46] .  These, however, are point-to-point lines, which
  865. are comparatively easy to protect.
  866.  
  867. A  multi-point  link  encryption  device  for  TCP/IP  is  the Blacker
  868. Front End (BFE) [47] .  The BFE looks to the host like an X.25 DDN
  869. interface, and sits between the host and the actual DDN line.  When it
  870. receives a call request packet specifying a new destination, it contacts an
  871. Access Control Center (ACC) for permission, and a Key Distribution Center
  872. (KDC) for cryptographic keys.  If the local host is denied permission to
  873. talk to the remote host, an appropriate diagnostic code is returned.  A
  874. special ``Emergency Mode'' is available for communications to a restricted
  875. set of destinations at times when the link to the KDC or ACC is not working.
  876.  
  877. The permission-checking can, to some extent, protect against the DNS attacks
  878. described earlier.  Even if a host has been mislead about the proper IP
  879. address for a particular destination, the BFE will ensure that a totally
  880. unauthorized host does not receive sensitive data.  That is, assume that a
  881. host wishes to send Top Secret data to some host foo.  A DNS attack might
  882. mislead the host into connecting to penetrated host 4.0.0.4, rather than
  883. 1.0.0.1.  If 4.0.0.4 is not cleared for Top Secret material, or is not
  884. allowed communications with the local host, the connection attempt will
  885. fail.  To be sure, a denial of service attack has taken place; this, in the
  886. military world, is far less serious than information loss.
  887.  
  888. The  BFE  also  translates  the  original  (``Red'')  IP  address  to  an
  889. encrypted (``Black'') address, using a translation table supplied by the
  890. ACC.  This is done to foil traffic analysis techniques, the bane of all
  891. multi-point link encryption schemes.
  892.  
  893. End-to-end  encryption,  above  the  TCP  level,  may  be  used  to  secure
  894. any conversation, regardless of the number of hops or the quality of the
  895. links.  This is probably appropriate for centralized network management
  896. applications, or other point-to-point transfers.  Key distribution and
  897. management is a greater problem, since there are more pairs of
  898. correspondents involved.  Furthermore, since encryption
  899.  
  900. - 13 -
  901.  
  902. and decryption are done before  initiation  or  after  termination  of  the
  903. TCP processing, host-level software must arrange for the translation; this
  904. implies extra overhead for each such conversation 10 .
  905.  
  906. End-to-end  encryption  is  vulnerable  to  denial  of  service  attacks,
  907. since fraudulently-injected packets can pass the TCP checksum tests and make
  908. it to the application.  A combination of end-to-end encryption and
  909. link-level encryption can be employed to guard against this.  An intriguing
  910. alternative would be to encrypt the data portion of the TCP segment, but not
  911. the header; the TCP checksum would be calculated on the cleartext, and hence
  912. would detect spurious packets.  Unfortunately, such a change would be
  913. incompatible with other implementations of TCP, and could not be done
  914. transparently at application level.
  915.  
  916. Regardless  of  the  method  used,  a  major  benefit  of  encrypted
  917. communications is the implied authentication they provide.  If one assumes
  918. that the key distribution center is secure, and the key distribution
  919. protocols are adequate, the very ability to communicate carries with it a
  920. strong assurance that one can trust the source host's IP address for
  921. identification.
  922.  
  923. This  implied  authentication  can  be  especially  important  in
  924. high-threat situations.  A routing attack can be used to ``take over'' an
  925. existing connection; the intruder can effectively cut the connection at the
  926. subverted machine, send dangerous commands to the far end, and all the while
  927. translate sequence numbers on packets passed through so as to disguise the
  928. intrusion.
  929.  
  930. It  should  be  noted,  of  course,  that  any  of  these  encryption
  931. schemes provide privacy.  Often that is the primary goal of such systems.
  932.  
  933. 7.3  Trusted Systems
  934.  
  935. Given  that  TCP/IP is  a  Defense  Department  protocol  suite,  it  is
  936. worth asking to what extent the Orange Book [48] and Red Book [49] criteria
  937. would protect a host from the attacks described above.  That is, suppose
  938. that a target host (and the gateways!) were rated B1 or higher.  Could these
  939. attacks succeed? The answer is a complex one, and depends on the assumptions
  940. we are willing to make.  In general, hosts and routers rated at B2 or higher
  941. are immune to the attacks described here, while C2-level systems are
  942. susceptible.  B1-level systems are vulnerable to some of these attacks, but
  943. not all.
  944.  
  945. In  order  to  understand  how  TCP/IP  is  used  in  secure  environments,
  946. a brief tutorial on the military security model is necessary.  All objects
  947. in the computer system, such as files or network channels, and all data
  948. exported from them, must have a label indicating the sensitivity of the
  949. information in them. This label includes hierarchical components (i.e.,
  950. Confidential, Secret, and Top Secret) and non hierarchical components.
  951. Subjects -- i.e., processes within the computer system -- are similarly
  952. labeled.  A subject may read an object if its label has a higher or equal
  953. hierarchical level and if all of the object's non-hierarchical components
  954. are included in the subject's label.  In other words, the process must have
  955. sufficient clearance for the information in a file.  Similarly, a subject
  956. may write to an object if the object has a higher or equal level and the
  957. object's non-hierarchical components include all of those in the subject's
  958. level.  That is, the sensitivity level of the file must be at least as high
  959. as that of the process.  If it were not, a program with a high clearance
  960. could write classified data to a file that is readable by a process with a
  961. low security clearance.
  962.  
  963. A  corollary  to  this  is  that  for  read/write  access  to  any  file,
  964. its security label must exactly match that of the process.  The same applies
  965. to any form of bidirectional interprocess communication (i.e., a TCP virtual
  966. circuit): both ends must have identical labels.
  967.  
  968. We  can  now  see  how  to  apply  this  model  to  the  TCP/IP  protocol
  969. suite.  When a process creates a TCP connection, that connection is given
  970. the process's label.  This label is encoded in the IP security option. The
  971. remote TCP must ensure that the label on received packets matches that of
  972. the receiving process.
  973.  
  974. __________________
  975.  
  976. 10. We are assuming that TCP is handled by the host, and not by a front-end
  977. processor.
  978.  
  979. - 14 -
  980.  
  981. Servers  awaiting  connections  may  be  eligible  to  run  at  multiple
  982. levels; when the connection is instantiated, however, the process must be
  983. forced to the level of the connection request packet.
  984.  
  985. IP  also  makes  use  of  the  security  option [50] .  A  packet  may  not
  986. be sent over a link with a lower clearance level.  If a link is rated for
  987. Secret traffic, it may carry Unclassified or Confidential traffic, but it
  988. may not carry Top Secret data.  Thus, the security option constrains routing
  989. decisions.  The security level of a link depends on its inherent
  990. characteristics, the strength of any encryption algorithms used, the
  991. security levels of the hosts on that network, and even the location of the
  992. facility.  For example, an Ethernet cable located in a submarine is much
  993. more secure than if the same cable were running through a dormitory room in
  994. a university.
  995.  
  996. Several points follow from these constraints.  First, TCP-level attacks can
  997. only achieve penetration at the level of the attacker.  That is, an attacker
  998. at the Unclassified level could only achieve Unclassified privileges on the
  999. target system, regardless of which network attack was used 11 .  Incoming
  1000. packets with an invalid security marking would be rejected by the gateways.
  1001.  
  1002. Attacks  based  on  any  form  of  source-address  authentication  should
  1003. be rejected as well.  The Orange Book requires that systems provide secure
  1004. means of identification and authentication; as we have shown, simple
  1005. reliance on the IP address is not adequate.  As of the B1 level,
  1006. authentication information must be protected by cryptographic checksums when
  1007. transmitted from machine to machine 12 .
  1008.  
  1009. The authentication server  is still  problematic;  it  can be spoofed  by a
  1010. sequence number attack, especially if netstat is available.  This sort of
  1011. attack could easily be combined with source routing for full interactive
  1012. access.  Again, cryptographic checksums would add significant strength.
  1013.  
  1014. B1-level  systems  are  not  automatically  immune  from  routing  attacks;
  1015. RIP-spoofing could corrupt their routing tables just as easily.  As seen,
  1016. that would allow an intruder to capture passwords, perhaps even some used on
  1017. other trusted systems.  To be sure, the initial penetration is still
  1018. restricted by the security labelling, but that may not block future logins
  1019. captured by these means.
  1020.  
  1021. Routing attacks can also be used for denial of service.  Specifically, if
  1022. the route to a secure destination is changed to require use of an insecure
  1023. link, the two hosts will not be able to communicate.  This change would
  1024. probably be detected rather quickly, though, since the gateway that noticed
  1025. the misrouted packet would flag it as a security problem.
  1026.  
  1027. At  the  B2  level,  secure  transmission  of  routing  control  information
  1028. is required.  Similar requirements apply to other network control
  1029. information, such as ICMP packets.
  1030.  
  1031. Several  attacks  we  have  described  rely  on  data  derived  from
  1032. ``information servers'', such as netstat and finger.  While these, if
  1033. carefully done, may not represent a direct penetration threat in the
  1034. civilian sense, they are often seen to represent a covert channel that may
  1035. be used to leak information.  Thus, many B division systems do not implement
  1036. such servers.
  1037.  
  1038. In  a  practical  sense,  some  of  the  technical  features  we  have
  1039. described may not apply in the military world.  Administrative rules [51]
  1040. tend to prohibit risky sorts of interconnections; uncleared personnel are
  1041. not likely to have even indirect access to systems containing Top Secret
  1042. data.  Such rules are, most likely, an accurate commentary on anyone's
  1043. ability to validate any computer system of non-trivial size.
  1044.  
  1045. 8.  CONCLUSIONS
  1046.  
  1047. Several  points  are  immediately  obvious  from  this  analysis.  The
  1048. first, surely, is that in general, relying on the IP source address for
  1049. authentication is extremely dangerous 13 .  Fortunately, the Internet
  1050.  
  1051. __________________
  1052.  
  1053. 11. We are assuming, of course, that the penetrated system does not have
  1054. bugs of its own that would allow further access.
  1055.  
  1056. 12. More precisely, user identification information must be protected to an
  1057. equal extent with data sensitivity labels.  Under certain circumstances,
  1058. described in the Red Book, cryptographic checks may be omitted.  In general,
  1059. though, they are required.
  1060.  
  1061. 13. There  are  some  exceptions  to  this  rule.  If  the  entire  network,
  1062. and all of its components (hosts, gateways, cables, etc.) are physically
  1063. protected, and if all of the operating systems are sufficiently secure,
  1064. there would seem to be little risk.
  1065.  
  1066. - 15 -
  1067.  
  1068. community  is  starting  to  accept  this  on  more  than  an  intellectual
  1069. level.  The Berkeley manuals [3] have always stated that the authentication
  1070. protocol was very weak, but it is only recently that serious attempts (i.e.,
  1071. Kerberos [35] and SunOS 4.0's DES authentication mode [52] ) have been made
  1072. to correct the problem. Kerberos and SunOS 4.0 have their weaknesses, but
  1073. both are far better than their predecessor.  More recently, an extension to
  1074. the Network Time Protocol (NTP) [53] has been proposed that includes a
  1075. cryptographic checksum [54] .
  1076.  
  1077. A  second  broad  class  of  problems  is  sequence  number  attacks.  If  a
  1078. protocol depends on sequence numbers -- and most do -- it is vital that they
  1079. be chosen unpredictably.  It is worth considerable effort to ensure that
  1080. these numbers are not knowable even to other users on the same system.
  1081.  
  1082. We  may  generalize  this  by by  stating  that hosts  should  not  give
  1083. away knowledge gratuitously.  A finger server, for example, would be much
  1084. safer if it only supplied information about a known user, rather than
  1085. supplying information about everyone logged on.  Even then, some censorship
  1086. might be appropriate; a refusal to supply the last login date and other
  1087. sensitive information would be appropriate if the account was not used
  1088. recently.  (Never-used accounts often have simple default passwords. 
  1089. Infrequently-used accounts are often set up less carefully by the owner.) We
  1090. have also seen how netstat may be abused; indeed, the combination of netstat
  1091. with the authentication server is the single strongest attack using the
  1092. standardized Internet protocols.
  1093.  
  1094. Finally, network control mechanisms are dangerous, and must be carefully
  1095. guarded.  Static routes are not feasible in a large-scale network, but
  1096. intelligent use of default routes and verifiable point-to-point routing
  1097. protocols (i.e., EGP) are far less vulnerable than broadcast-based routing.
  1098.  
  1099. 9.  ACKNOWLEDGEMENTS
  1100.  
  1101. Dave  Presotto,  Bob  Gilligan,  Gene  Tsudik,  and  especially  Deborah
  1102. Estrin made a number of useful suggestions and corrections to a draft of
  1103. this paper.
  1104.  
  1105. REFERENCES
  1106.  
  1107. 1. E.J.  Feinler,  O.J.  Jacobsen,  M.K.  Stahl,  C.A.  Ward,  eds. DDN
  1108. Protocol Handbook.  DDN Network Information Center, SRI International, 1985.
  1109.  
  1110. 2. Comer,  D. Internetworking  with  TCP/IP  :  Principles,  Protocols,  and
  1111. Architecture.  Prentice Hall, 1988
  1112.  
  1113. 3. Computer  Systems  Research  Group. UNIX User's Reference  Manual  (URM). 
  1114. 4.3 Berkeley Software Distribution Virtual Vax-11 Version. Computer Science
  1115. Division, Department of Electrical Engineering and Computer Science,
  1116. University of California, Berkeley.  1986.
  1117.  
  1118. 4. Spafford,  E.H. The  Internet  Worm  Program:  An  Analysis.  Purdue
  1119. Technical Report CSD-TR-823, Department of Computer Sciences Purdue
  1120. University, West Lafayette, IN.  1988
  1121.  
  1122. 5. Seeley, D. A Tour of the Worm.  Department of Computer Science,
  1123. University of Utah.  1988.
  1124.  
  1125. 6. Eichin,  M.  and  Rochlis,  J. With  Microscope  and  Tweezers:  An
  1126. Analysis of the Internet Virus of November 1988. Massachussetts Institute of
  1127. Technology, 1988.
  1128.  
  1129. 7. Morris,  R.T.  1985. A  Weakness  in  the  4.2BSD  UNIX TCP/IP  Software. 
  1130. Computing Science Technical Report No. 117, AT&T Bell Laboratories, Murray
  1131. Hill, New Jersey.
  1132.  
  1133. 8. Reynolds, J.K., and J. Postel. Assigned Numbers.  RFC 990, 1986
  1134.  
  1135. 9. Mills, D.L. Internet Delay Experiments, RFC 889, 1983.
  1136.  
  1137. - 16 -
  1138.  
  1139. 10. Blum, M. and Micali, S.  ``How to Generate Cryptographically Strong
  1140. Sequences of Pseudo-Random Bits''. SIAM J. Computing, vol. 13, no. 4, pp.
  1141. 850-864, Nov. 1984.
  1142.  
  1143. 11. US  Federal  Information  Processing  Standards  Publication  (FIPS
  1144. PUB) 46, Data Encryption Standard, 15 January 1977.
  1145.  
  1146. 12. US  Federal  Information  Processing  Standards  Publication  (FIPS
  1147. PUB) 81. DES Modes of Operation, 2 December 1980.
  1148.  
  1149. 13. Bishop,  M. An  Application  of  a  Fast  Data  Encryption  Standard
  1150. Implementation.  Technical Report PCS-TR88-138, Department of Mathematics
  1151. and Computer Science, Dartmouth College, Hanover, NH.  1988.
  1152.  
  1153. 14. Mogul,  J.  ``Simple  and  Flexible  Datagram  Access  Controls  for
  1154. UNIX-based Gateways'', Proceedings, Summer USENIX, 1989, Baltimore, Maryland
  1155. (to appear).
  1156.  
  1157. 15. Hedrick, C. Routing Information Protocol.  RFC 1058, 1988.
  1158.  
  1159. 16. Mills, D.L. Exterior Gateway Protocol Formal Specification.  RFC 904,
  1160. 1984.
  1161.  
  1162. 17. Postel, J. Internet Control Message Protocol.  RFC 792, 1981.
  1163.  
  1164. 18. St. Johns, M. Authentication Server.  RFC 931, 1985.
  1165.  
  1166. 19. Defense  Advanced  Research  Projects  Agency,  Internet  Activities
  1167. Board. IAB Official Protocol Standards. RFC 1083, 1988
  1168.  
  1169. 19. Postel, J.  Private communication.  1989.
  1170.  
  1171. 20. Needham,  R.M.  and  Schroeder,  M.D.  ``Using  Encryption  for
  1172. Authentication in Large Networks of Computers''. Communications of the ACM,
  1173. vol. 21, no. 12, pp. 993-999, December 1978.
  1174.  
  1175. 21. Denning,  D.E.  and  Sacco,  G.M.  ``Timestamps  in  Key  Distribution
  1176. Protocols'', Communications of the ACM, vol. 24, no. 8, pp. 533-536, August
  1177. 1981.
  1178.  
  1179. 22. Needham,  R.M.  and  Schroeder,  M.D.  ``Authentication  Revisited'',
  1180. Operating Systems Review, vol. 21, no. 1, p. 7, January 1987.
  1181.  
  1182. 23. Harrenstien, K. NAME/FINGER Protocol, RFC 742, 1977.
  1183.  
  1184. 24. Grampp,  F.T.  and  Morris,  R.H.  ``UNIX Operating  System  Security'',
  1185. AT&T Bell Laboratories Technical Journal, vol. 63, no. 8, part 2, October,
  1186. 1984.
  1187.  
  1188. 25. Crocker, D. Standard for the Format of ARPA-Internet Text Messages.  RFC
  1189. 822, 1982.
  1190.  
  1191. 26. Postel, J. Simple Mail Transfer Protocol.  RFC 821, 1982.
  1192.  
  1193. 27. Linn,  J. Privacy  Enhancement  for  Internet  Electronic  Mail:  Part
  1194. I: Message Encipherment and Authentication Procedures.  RFC 1040, 1988.
  1195.  
  1196. 28. Butler, M.; Postel, J.B.;  Chase,  D.;  Goldberger,  J.;  Reynolds,
  1197. J.K. Post Office Protocol - Version 2. RFC 937, 1985.
  1198.  
  1199. 29. Diffie,  W.  ``The  First  Ten  Years  of  Public  Key  Cryptography''.
  1200. Proc.  IEEE, vol.  76, no.  5, pp. 560-577, May 1988.
  1201.  
  1202. 30. Rose, M. Post Office Protocol - Version 3.  RFC 1081, 1988
  1203.  
  1204. 31. Lambert, M.L. PCMAIL: A Distributed Mail System for Personal Computers. 
  1205. RFC 1056, 1988
  1206.  
  1207. 32. Mockapetris, P. Domain Names - Concepts and Facilities.  RFC 1034, 1987.
  1208.  
  1209. 33. Mockapetris, P. Domain Names - Implementations and Specifications.  RFC
  1210. 1035, 1987.
  1211.  
  1212. - 17 -
  1213.  
  1214. 34. Dyer, S.P.  ``Hesiod'', Proceedings, Winter USENIX, 1988, Dallas, Texas.
  1215.  
  1216. 35. Steiner,  J.G,  Neuman,  C.,  Schiller,  J.I.  ``Kerberos:  An
  1217. Authentication Service for Open Network Systems'', Proceedings, Winter
  1218. USENIX, 1988, Dallas, Texas.
  1219.  
  1220. 36. Postel, J. File Transfer Protocol.  RFC 959, 1985.
  1221.  
  1222. 37. Case,  J.,  Fedor,  M.,  Schoffstall,  J.,  and  Davin,  J. A  Simple
  1223. Network Management Protocol.  RFC 1067, 1988.
  1224.  
  1225. 38. McCloghrie,  K.  and  Rose,  M. Management  Information  Base  for
  1226. Network Management of TCP/IP based Internets.  RFC 1066.  1988.
  1227.  
  1228. 39. Finlayson,  R.;  Mann,  T.;  Mogul,  J.;  Theimer,  M. Reverse  Address
  1229. Resolution Protocol.  RFC 903, 1984.
  1230.  
  1231. 40. Sollins, K.R. The TFTP Protocol (Revision 2).  RFC 783, 1981.
  1232.  
  1233. 41. Croft, W.J.; Gilmore, J. Bootstrap Protocol.  RFC 951, 1985.
  1234.  
  1235. 42. Plummer, D.C. An Ethernet Address Resolution Protocol.  RFC 826, 1982.
  1236.  
  1237. 43. Diffie,  W.  and  Hellman,  M.E.  ``New  Directions  in  Cryptography.''
  1238. IEEE Transactions on Information Theory, vol. IT-22, no. 6, pp. 644-654.
  1239.  
  1240. 44. Voydock,  V.L.  and  Kent,  S.T.  ``Security  Mechanisms  in  High-Level
  1241. Network Protocols''. ACM Computer Surveys, vol. 15, no. 2, pp. 135-171, June
  1242. 1983.
  1243.  
  1244. 45. Davies, D.W. and Price, W.L. Security for Computer Networks: An
  1245. Introduction to Data Security in Teleprocessing and Electronic Funds
  1246. Transfer. Wiley.  1984.
  1247.  
  1248. 46. Defense Communications Agency. Defense Data Network Subscriber Security
  1249. Guide.  1983.
  1250.  
  1251. 47. ``Blacker  Front  End  Interface  Control  Document'',  in DDN  Protocol
  1252. Handbook.  DDN Network Information Center, SRI International, vol. 1, 1985.
  1253.  
  1254. 48. DoD  Computer  Security  Center. DoD  Trusted  Computer  System
  1255. Evaluation Criteria, 1983, CSC STD-001-83.
  1256.  
  1257. 49. National Computer Security Center. Trusted Network Interpretation of the
  1258. Trusted Computer System Evaluation Criteria.  NCSC-TG-005, Version 1, July
  1259. 31, 1987.
  1260.  
  1261. 50. St. Johns, M. Draft Revised IP Security Option.  RFC 1038, 1988.
  1262.  
  1263. 51. DoD  Computer  Security  Center. Technical  Rationale  Behind
  1264. CSC-STD-003-85: Computer Security Requirements, CSC-STD-004-83, 1983.
  1265.  
  1266. 52. Taylor,  B.  and Goldberg,  D.  ``Secure  Networking  in  the  Sun
  1267. Environment''. Proceedings, Summer USENIX, 1986, Atlanta, Georgia.
  1268.  
  1269. 53. Mills,  D.L. Network  Time  Protocol  (Version  1)  Specification  and
  1270. Implementation.  RFC 1059, 1988.
  1271.  
  1272. 54. Mills, D.L.  Mailing list message <8901192354.aa03743@Huey.UDEL.EDU>,
  1273. January 19, 1989.
  1274.  
  1275.